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Cc: Ron Kair 

Subject: VRTS 0623: Coherently sharing any form of ?instant? snapshot separately from base volumes 

VERITAS CONFIDENTIAL 



Invention Disclosure Form 



Name: Ronald Karr 
Telephone: 650*527-8439 
Email: tron@verlta8.com 

2. Provide a brief descriptive title of the invention: 

Coherently sharing any form of "Instanf* snapshot separately from base volumes 

3. In SO words or less, please provide an abstract or summary of the invention: 

SANVM as well as CVM and VxVM support instant snapshots, as described In various other patents. This patent 
uses SANVM, CVM, XVM, or perhaps Switch-based VM with LUN tunneling to provide access to an instant 
snapshot from a second system. 

4. List all inventors who contributed to this invention (if more than four, please provide the additional names in the space 
provided): 

1st Contributer Name: Ronald Karr 
1st Contributer Division: Engineering 
1st Contributer Campus: MTV 
1st Contributer Phone: 650-527-8439 
1st Contributer eMail: tron@verita8Xom 
VERITAS Employee? yes 

2nd Contributer Name: Anand Kekre 
2nd Contributer Division: Engineering 
2nd Contributer Campus: Rune 
2nd Contributer Phone: 

2nd Contributer eMail: anand.kel(re@veritas.com 
VERITAS Employee? yes 

3rd Contributer Name: 
3rd Contributer Division: 
3rd Contributer Campus: 
3rd Contributer Phone: 
3rd Contributer eMail: 
VERITAS Employee? 

4th Contributer Name: 
4th Contributer Division: 
4th Contributer Campus: 
4th Contributer Phone: 
4th Contributer eMail: 
VERITAS Employee? 
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Introduction 

SANVM, XVM, and some of the designs for switch-based VxVM depend on extending the architecture of VERITAS 
Volume Manager, by giving it a very flexible form of storage sharing. They are all based on distributed block 
virtualizatiott, which extends the basic concept of single node and symmetrically clustered virtual block devices into 
flexibly distributed block virtualization components. 

SAN VM, XVM, and switch-based VxVM differ in how they intend to distribute components of block virtualization, 
but they share many structural similarities. Distributed virtualization itself is an important concept that will likely be 
very important to the future of block storage. 

Basic software structure 

Distributed block virtualization basically distributes a description of how a virtual block device (for example, a 
logical volume or a virtual LUN) relates to underlying storage, as well as how distributed block virtualization 
components might relate in order to accomplish certain functions. 

Block virtualization components can live in various places. They can be software layers on servers that run file 
systems or databases. They can be in the disk arrays. They can be in intermediate devices residing in storage networks 
between hosts and disk arrays. They can be in the host bus adapters that connect a host to a network. Any of these 
components could participate in some form of distributed virtualization. It is also possible that any of these 
components could implement a non-distributed virtualization even though other components do implement 
distributed virtualization. Components can cooperate to provide distributed virtualization either across a layer or 
between layers, or layered components can implement isolated virtualization layers where a higher layer uses a lower 
layer in the same way the upper layer would simply use a disk drive. 

A typical implementation of distributed block virtualization will have components running on some collection of 
nodes to identify and organize some collection of underlying logical disks {device management). Additionally, they 
will have configuration management components that store and retrieve information that describes the logical 
structure associated with the virtualization (how logical and physical disks are divided, aggregated, mirrored, and so 
on). Various distributed xnrtualization coordination components analyze the logical structure and communicate 
inf onnation about that structure to the various I/O engines that receive and transform read and write requests (the 
incoming I/O stream) to virtual block devices and convert them into network messages and reads and writes to 
underlying logical and physical disk drives. 

The configuration associated with a virtual block device may change over time, such as to add or remove mirrors; 
migrate data to new storage; increase or decrease the size of the device; create, manipulate, or remove snapshots; add 
structure for a new capability; etc. Changes that affect several I/O engines must often result in coherent updates that 
are effectively atomic relative to some aspect of the I/O stream. This is generally done through some kind of 
distributed transactional update, coupled with some form of I/O quiesce, which temporarily blocks activity while 
distributed structures are updated. 

Figure 1 graphically depicts a typical logical volume-based block virtualizer, such as that implemented by SANVM. A 
coordinator, in SANVM called a volume server, serves the configuration management and distributed virtualization 
coordination functions. The SANVM volume server reads and updates configuration information from VxVM 
configuration databases (which are actually stored on the disks that are being virtualized) in persist and retrieve the 
logical configuration. The logical configuration for a single voltune is depicted in figure 1 as a tree of virtual objects. 
This tree is coherently communicated and updated to all the nodes that share access to that volume. Each node can 
then independendy use that tree of virtual objects to transform the I/O stream coming into the I/O engine on that node 
into I/O requests directly to the physical disks that underlie the volume. 
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SANVM also has another software component (called a log coordinator) that is an example of a special component 
that coordinates some virtualization function. The log coordinator in SANVM coordinates update activity associated 
with recoverable mirroring and snapshots. Sucti JuncHon coordinator components are likely to be prevalent within 
many distributed virtualization implementations. 



12. Has the invention been built or implemented? If so. please provide the particulars of the first time it was successfully 
built or implemented (when, where, by whom, and evidence of this event including written or on-line pointers to 
documentary evidence): 
It Is in CVM 4.0 and will be in SANVM. 



15. Please provide the names of products that the invention is, or will be used in (if any): 
Primary product invention is used in: SANVM 

Other products Invention may be used in: CVM and Switch versions of SANVM 
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